Addressed the review findings in add04df. Specifically: (1) TS now deduplicates repeated named export blocks from per-method json-schema-to-typescript compiles, which removes the duplicate SessionMode and duplicate UiElicitationResponse declarations; and (2) the Go/Python quicktype-based generators now collapse placeholder *Class duplicates onto the explicit titled type when the structures are identical, so HandlePendingElicitationRequest.result now uses UIElicitationResponse instead of ResultClass.

Full disclosure 01: using my human brain Java subject matter expertise, Opus 4.6, and existing context, I arrived at these comments, in light of the comments Stephen posted to Slack.

Full disclosure 02: The current agentic workflow derives the Java SDK directly from the post-code-generated parts of the reference implementation. I have an outstanding work item ( https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2751554 ) to make it so the Java SDK also uses the Zod schema, in addition to the agentic workflow to reduce toil in keeping the Java SDK in synch with the .NET and TypeScript reference implementations (See agentic workflow). Therefore, my comments are to be taken in light of what I would like to see before I undertake the work to implement dd-2751554-do-code-gen-for-java.

Disclosures aside, I stand by the following comments.

1. Reinforce @stephentoub 's point on empty types — with a Java-specific angle

+1 on eliminating empty result types. From the Java SDK perspective, the 13 empty types (PlanUpdateResult, AgentDeselect, SkillsEnableResult, McpReload, etc.) present an awkward ergonomics issue. Java doesn't have Task vs Task<T> — we use CompletableFuture<Void> for void results. Generating an empty record like public record McpReload() {} would feel unnatural to Java developers and force consumers to handle a meaningless return type. If the schema expressed these as null/void results, each language generator could map to its natural void representation (Task in C#, CompletableFuture<Void> in Java, None in Python, empty struct or no return in Go).

Question: Would it make sense for empty result schemas to be represented as null in the API schema rather than { "type": "object", "properties": {} }? That way generators could choose void/Void without needing per-language special-casing. Happy to discuss if there's a reason the current shape is preferred.

2. Reinforce the duplicate types point — with specific examples

+1 on consolidating identical structures. The Agent group stood out to me: Agent, AgentCurrentAgent, AgentSelectAgent, and AgentReloadAgent are structurally identical (all have name, displayName, description). Similarly, ModelCurrent and ModelSwitchToResult both wrap a single modelId: string?. And four types (UiElicitationResult, PermissionRequestResult, HandleToolCallResult, CommandsHandlePendingCommandResult) are all { success: boolean }.

In Java, each of these becomes a separate record class. The naming machinery in PR 5908 does a nice job producing clean names for them, but I wonder if we could go a step further: would it be feasible to define a shared Agent schema (with $ref) and have agent.select, agent.current, and agent.reload all reference it? I noticed that hoistTitledSchemas() already deduplicates schemas that share the same title — so maybe it's just a matter of giving these inline definitions a shared title? I might be missing a reason they need to be separate.

3. Namespacing: Java has a different approach than C# nested types

On the namespacing suggestion: For context on how this lands in Java — our natural namespacing mechanism is packages, not nested classes. Where C# would nest Agent.SelectResult inside a class Agent, Java would typically use com.github.copilot.sdk.rpc.agents.SelectResult. This tends to work well in practice because:

• It avoids the Agent.Agent pattern (outer class and inner class sharing a name, which is a Java code smell).
• It aligns with how Jackson deserialization resolves types.
• It enables per-package package-info.java for group documentation.

One thing I'd love to explore: package-based namespacing would benefit from the schema carrying some grouping information so generators know which package/namespace a type belongs to. Today, the schema titles are flat strings (AgentSelectResult, McpConfigServerLocal). I'm wondering whether it might be worth considering an optional group or namespace annotation alongside title — that way each language generator could map to its natural grouping mechanism (packages in Java, nested types in C#, module prefixes in Python) without parsing the group from the type name string. This may be out of scope for this PR, but wanted to plant the seed.

4. Java-specific observation: the MCP filter mapping type explosion

From the Java SDK perspective, the MCP config types are a notable hotspot. There are 18 FilterMapping variant types across 6 contexts (server local, server http, add local, add http, update local, update http) — structurally identical in groups of 3. In Java, each would become a separate sealed interface + record hierarchy, with identical Jackson @JsonTypeInfo/@JsonSubTypes annotations multiplied 6×.

This hasn't been an issue in practice because the Java SDK hasn't implemented MCP config types yet (it was easy to skip when hand-writing). With codegen, they'd all materialize automatically. I'm curious — is there a reason these can't share a single McpConfigFilterMapping definition with $ref? There may be a forward-compatibility reason I'm not seeing for keeping them separate.

5. Stability guarantee + Java sealed types interaction

The stability guarantee from PR 5908 (new schemas never rename existing types) is very welcome. One subtlety for Java: with sealed interfaces/classes, adding a new event type requires updating the permits clause on the base type. This means the generated base type changes on every new event — which is fine since it's generated. But it also means consumers who do exhaustive switch on event types will get compile warnings when new events are added. This is actually desirable behavior (it's the point of sealed types), but it's worth documenting as an expected contract: adding a new event type in the runtime is a source-compatible but not pattern-exhaustiveness-compatible change.

6. Single-property wrappers: a different perspective from the Java side

On single-property wrapper types: I wanted to offer a slightly different perspective from the Java side. Stephen's suggestion to return the raw value directly (e.g., string instead of ShellExecResult { processId: string }) makes a lot of sense for .NET ergonomics. In Java, there's a tension: CompletableFuture<String> is less self-documenting than CompletableFuture<ShellExecResult>, and unwrapping removes the ability to add fields later without a breaking change.

One possible approach: Keep the wrapper types in the schema (for extensibility), but mark single-property types with a schema annotation (e.g., "unwrappable": true). Generators that prefer unwrapping (C#) could do so; generators that prefer wrapper types (Java, for future-proofing) could ignore it. This would avoid baking an unwrapping decision into the shared schema that all languages must follow. That said, I recognize this adds complexity to the schema — I'm open to simpler alternatives if others have ideas.

About empty result types: there were about 15 of these, and I've removed them all.

Well, the reality is a bit more complex: for Go we need to retain them for forward compat, which in turn means we also need to retain the name generator output from the runtime so we wouldn't break them name in the future if we changed from void to nonvoid.

I've updated things on both sides so that Go is able to produce empty result structs with the desired names, and the other languages use their own versions of void.

1. Reinforce @stephentoub 's point on empty types — with a Java-specific angle
   +1 on eliminating empty result types.

This is done, though it's not a perfect solution given that in Go it creates an extra forward-compat concern. The middle ground we're in now is:

• For Go, it continues to produce empty result types so the return value can be (*SomeType, error)
• For other languages it now uses their version of void/async-void

In the future, if we want to change these methods to be nonvoid, we will be constrained to give them the type SomeType and not anything else (not a primitive, not some other name) for compatibility with existing Go code.

2. Reinforce the duplicate types point — with specific examples

Valid but we must do this through runtime schema changes (e.g., using $ref). We can't collapse types just because they are structurally equivalent as that would be breaking if they stop being equivalent later. So likely we should keep that out of scope until we add $ref in @stephentoub's PR.

3. Namespacing: Java has a different approach than C# nested types

This PR is already quite hard to land so would be good to get in what we have before we think about systems for nesting types. Given the large differences between languages (e.g., how TypeScript doesn't have any global namespace) it might or might not be productive to try to have a unified model here.

4. Java-specific observation: the MCP filter mapping type explosion

We can change whatever we think is best on the runtime schema side. For this PR I'm trying to focus on the machinery that generates the JSON schema and then renders that out into per-language code.

5. Stability guarantee + Java sealed types interaction
   adding a new event type in the runtime is a source-compatible but not pattern-exhaustiveness-compatible change.

Understood, thanks.

7. Single-property wrappers: a different perspective from the Java side

With the example given (CompletableFuture<String> vs CompletableFuture<ShellExecResult>), it's no different from in .NET (Task<string> vs Task<ShellExecResult>). So I'm not sure there's any Java-vs-.NET reason to vary the representation. We can't say that the ability to add more properties in the future is a reason to have some but not all languages use wrappers - either they must all do it, or none of them can, since changing a primitive return to an object return would be breaking.

The way the machinery works now is that the runtime schema decides whether a given method's return value is a raw primitive or is wrapped in some object. The person authoring that schema has to decide on the likelihood of needing to add extra properties in the future.

I think our options are:

• Risk averse - say we always think more might be added, and hence require every RPC method to return a wrapper *Result type (even things that would otherwise be void). That's what we had before all this work but @stephentoub was recommending not to do that.
• Let the runtime schema decide - we have a case-by-case decision about how we want to represent the RPC result and whether it might be expandable with other properties in the future. The ergonomics are better, at the cost that it's more painful if our guess turns out to be wrong.

Can we decide which of these two we're going for? I've implemented the second option and am happy to stick with that unless there are big concerns.

Let the runtime schema decide - we have a case-by-case decision about how we want to represent the RPC result and whether it might be expandable with other properties in the future.

I think this is the right answer. The runtime here is the source-of-truth for the shape of the API, and the developer of that API needs to say whether there's any possibility it could be expanded in the future.

Cross-SDK Consistency Review

This PR does a thorough job updating type names across all four SDKs (TypeScript, Go, Python, .NET) — the Python files were included too (pagination limited the initial file listing to 30 files but the diff includes python/copilot/generated/rpc.py, session.py, client.py, and test files).

✅ Well-handled language-idiomatic differences

The following differences are appropriate for each language and don't represent inconsistencies:

⚠️ One genuine inconsistency found

MCPServerSource (Go/Python) vs DiscoveredMcpServerSource (.NET)

This PR renamed Go and Python's ServerSource enum → MCPServerSource. However, the .NET SDK was already using DiscoveredMcpServerSource for the same enum values (user/workspace/plugin/builtin). The two names now diverge.

Note: this enum is used for both DiscoveredMCPServer.source and MCPServer.source fields, so the Discovered prefix in .NET is arguably a misnomer regardless.

I've left an inline comment on the Go generated file with more details. The fix would be to either:

• Rename .NET's DiscoveredMcpServerSource → McpServerSource in the C# codegen (aligning with Go/Python), or
• Use DiscoveredMCPServerSource in Go/Python to match .NET

Otherwise the naming improvements in this PR look consistent and well-reasoned. 👍

Generated by SDK Consistency Review Agent for issue #1043 · ● 3.5M · ◷